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Description 

[0001 ] The present invention relates to a method for performing mobile services on a mobile device having a micro- 
processor smart card, to a software program for executing such a method, to a microprocessor smart card for a mobile 
5 device as well as to a mobile telephone having such a smart card. 

[0002] The communication's habits of people have strongly changed over the years and Indeed show that in addition 
to voice communication data exchange (e-mail, SMS) has strongly increased. World-wide networking and the integra- 
tion of business processes in this network infrastructure now mean that the availability of electronic data has become 
- of vital importance. 

10 [0003] As the growth in mobile communications has shown, the need for location-independent infonmatlon exchange 
is very high. Although technical possible, the present-day offering can only fully satisfy requirements in the area of 
speech communications. The desire for mobile data exchange continues to grow. 

[0004] In the last time so-called smart cards found general interest. The term "smart card" lis generally used to des- 
ignate a card of given dimensions including a semiconductor enabling it to store and/or to process infomiation. Two 
15 types of smart cards can be distinguished: memory cards and microprocessor smart cards. 

[0005] Memory cards are unable to process information, they are simply storage devices, and in this respect are 
very similar to magnetic stripe cards. They have greater memory capacity but the same weakness regarding security. 
Memory cards are intended for basic application such as debiting telephone units! 

[0006] The present invention only relates to the use of microprocessor smart cards having high memory capacity in 
20 the microprocessor, enabling them not only to store information but also to carry out local processing on the data and 
perfomn complex algorithmic calculations. Such a smart card 2 with its chip , 14 comprising a microprocessor 15 is 
shown in figure 9. Well-known applications for microprocessor smart card consist in encrypting the infomiation ex- 
change by the card and implementing advanced security mechanisms to counter fraud attempts. Microprocessor smart 
cards therefore can be considered as a small computing device based on a plastic plate capable of supporting appli- 
es cations with advanced service and high guarantee of security with respect to users. The components of smart cards 
are a chip {simple memory or microprocessor component) and memories'like ROM, EEPROM and RAM. 
[0007] It is already known to use such microprocessor smart cards for mobile services, which are often also called 
over the air valued-added services. These systems work by transferring executable SMS commands over wireless 
networks to SIM cards. A SIM card is a smart card used in the GSM system. Theses systems are independent of the 
30 receiving mobile equipment. These solutions are offered by different companies. A server delivers SIM commands to 
a SMS centre. The SMS centre sends these SMS commands over the air (wireless network) to a mobile device such 
as a mobile telephone. Due to the transmission by means of SMS messages, the over the air capacity is limited. 
[0008] In view ofthe above problem the present invention has as an objectto improve the execution of mobile services 
on mobile devices having smart cards. 
35 [0009] This object is achieved by means of the features of the independent claims. The dependent claims develop 
further the central idea of the present invention. 

[001 0] According to a first aspect of the present invention a method for performing mobile services on a mobile device 
having a so-called smart card of the microprocessor type ("microprocessor smart card") is proposed. On the smart 
card downloaded mobile sen/ice program codes are respectively executed by means of a ( resident) interpreter platform 
40 for performing a mobile service. 

[0011] Mobile service data needed for performing the mobile services are transmitted to the mobile device and stored 
on the microprocessor smart card. The interpreter platfomn accesses the mobile service data for perfomiing the cor- 
responding mobile service. 

[0012] The mobile service data can tor example be stored in elementary files (EF) of the GSM file system or in an 
4s allocated memory used by the Interpreter platfomn. 

[0013] The interpreter platform can be divided in an interpreter part for processing mobile service program codes 

and a receiving part for transmitting data to and/or from a remote server. 

[0014] The interpreter platform can be particularly implemented by means of a JAVA applet. 

[001 5] The mobile service program code can be stored in an elementary file of the GSM file system or in an allocated 
so memory used by the interpreter platform. 

[0016] The transmission of mobile service program codes and/or mobile service data can be performed over a non- 
voice channel. 

[0017] The mobile service program codes can be downloaded by means of the SMS seryice of a GSM transmission 
system. 

55 [0018] The mobile service program code necessary for a mobile service can be assembled in a server and then be 
transmitted to the mobile service by means of a SMS service using a SMS centre. Alternatively single modules of the 
mobile sen/ice program code can be downloaded. 

[0019] The interpreter platfomn can consist of methods, wherein each method is associated with a dedicated memory 
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unit for storing the mobile sen/ice program code to be executed by said method. 

[0020] The transmission of mobile service program codes and/or mobile service data can be performed by means 
of data packets having a header and a data region. 

[0021] According to another aspect of the present invention a software program for executing a method as set forth 
5 ■ above is proposed. 

[0022] According to a still further aspect of the present invention a smart card for a mobile device such as a mobile 
telephone having stored thereon an interpreter platform for executing a method as set forth above is proposed. 
[0023] Finally, according to a still further aspect of the present invention, a mobile telephone having such a micro- 
processor smart card Is proposed. 
10 [0024] Further features, advantages and characteristics of the present Invention will become evident for the man 
skilled in the art when reading the following detailed description of an embodiment of the present invention taken in 
conjunction with the figures of the enclosed drawings. 

Figure 1 shows the downloading of mobile service programs, 

15 

Figure 2 shows a smart card having an interpreter platform and mobile service part. 

Figure 3 shows the transmission of data packets by means of a SMS system from a server to a mobile telephone 
and back, 

20 

Figure 4 shows the principle elements of a mobile service system according to the present invention, 
Figure 5 shows the intemal structure of a microprocessor smart card according to the present invention, 
25 Figure 6 shows advantageous applications of the present invention, 

Figure 7 shows the application of the present invention for the case of a mobile agenda, 
Figure 8 shows a flow chart demonstrating the method according to the present invention, and 

30 

Figure 9 shows a known microprocessor smart card. 

[0025] The present Invention proposes an application architecture of a microprocessor smart card which Is flexible 
and open for the integration of new mobile services. This Is only feasible taking into account the size of the mobile 
35 service program. Downloading of these mobile services programs can be effected via a SMS interface 1 as it is shown 
in figure 1, wherein a maximum of 160 characters (140 bytes) can be transferred with one SMS message. In case of 
SMS-PP the overhead (headers etc.) reduces the effective number even further, f.e. to 118 characters. Due to that fact 
the mobile service program has to be kept a few hundred bytes in size. In this case It can be downloaded easily with 
only a few SMS messages. 

40 [0026] As shown in figure 1 different mobile service programs are linked (assembled) in a ser/er (shown later on) 
and then transmitted as SMS-PP (point to point) rhessages 1 to a mobile device 8 such as a mobile telephone. Alter- 
natively single modules of the program code are downloaded. The mobile telephone 8 comprises a microprocessor 
smart card 2 (I.e. a SIM card in the case of the GSM system) which has an interpreter platfonn 3 with a receiving part 
1 2 and an interpreter part 1 3 as well as a service part. 

45 [0027] The mobile phone user can indicate to his office PC which mobile sen/ices he wants to have made available 
on his mobile phone 8. The needed mobile sen/ices program Is then assembled on a local server for the user and 
transferred to him via SMS. If the user language changes, then a new mobile service program in the selected foreign 
language will be transferred. The operating logic remair»s the same for the mobile services and only the text for the 
main use and displays changes. 

so [0028] As soon as the mobile service program which is needed to run a certain mobile service is downloaded on the 
smart card 2 of the mobile phone 8, mobile service data are transferred between the server 9 and the smart card 2 of 
the mobile phone 8. The mobile service data contain the information which is sent to and downloaded from the server 
9. It may contain commands sent to the server 9 and ordered read agenda infomnation (for example) in case the mobile 
service "agenda" is loaded and the information which is sent to the mobile phone. 

55 ■ [0029] In the following the mobile service program code will be explained. To keep the mobile service program code 
very compact a new command syntax/language has been developed. This is called mobile service program (MSP). 
The commands have a veiy high functionality (optimally conceived for compatibility) and are defined through a byte- 
code. The commands are picked out from the smart card and interpreted by the JAVA applet. An intemnediate buffer 
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(INBUF) is defined such that the commands can exchange data. Thus feedback values are stored In this intemnediate 
memory by Input commands and can be used further trough additional commands (e.g. SMS-PP). The commands 
start to the cornmand-byte, followed by several parameters, 

[0030] Figure 2 shows In detail the transmission of mobile service program codes and/or mobile service data as 
5 commands (for example a JAVA code, an assembler like code, ...) to the microprocessor smart card 2 in the mobile 
phone 8. 

[0031] In order to operate a mobile service, the user first selects the Interpreter platfonn applet 3 in the mobile phone 
8 and can then select the service in the menu that appears. The mobile phone user himself as well as others, e.g. the 
secretary in the office, can make a change in the agenda and then make this known generally to the other synchronised 

10 agenda users. This can be done via the mobile service data. Should the mobile phone 8 wish to download another 
service component, provided previously, then he can do this via the menu point "new mobile service". The mobile 
service program code which Is needed in order to run the mobile service remains stored in the smart card of the mobile 
phone 8 u ntil it is intentionally deleted. Switching on or off the mobile phone 8 does not erase the mobile service program. 
[0032] Alternatively an automatic update function can be provided which Is triggered on the side of the server and 

15 not of the mobile phone. In this case data and/or programs are updated as soon as the mobile phone is switched on. 
[0033] In order to satisfy the above requirements, the smart card comprises two Independent parts: 

a platform component and 

a service part (mobile services program). The platform component 3 in figure 2 interprets the mobile service pro- 
20 grams stored in elementary files 6 of a GSM file structure or in an allocated memory used by the interpreter platform 

and executes the commands (when accessed by the CPU of the smartcard). This platform 3 is independent of 
language and Is separate from the actual logical operation of the mobile services. The interpreter platform can f. 
e. be stored in_the EEPROIVI of the smart card 2. The separation of server's relevant functions allows to develop 
a compact applet which can provide a basis in the mobile telephone 8 for all services available today and in future. 

25 

[0034] The service part (see figure 1 and figure 5) is provided as mobile service program sequences (see figure 3) 
via an server 9. 

[0035] Note that an applet is a unit of selection, context, functionality and security In a JAVA card, i.e. a smartcard 
using the JAVA (trademark) programming language. 
30 [0036] The service part can f.e. be stored in the EEPROM of the smart card 2. In the program sequences a foreign 
language independent part, the service description (functionality, logical operation) and a small part of the associated 
data Is comprised. If additional mobile service data is supplied to be updated to a given mobile service (e.g. schedule 
data), this is effected again via the SMS interface. 

[0037] The separation of the functionality operation and the very corhpactly designed program code means that the 

35 mobile service program code is only a few hundred bytes large. 

[0038] Therefore, a maximum of functionality can be offered with a minimum of memory requirements. 
[0039] The mobile service program code is very compact (assembler type). The individual corhmands are optimally 
conceived for the compatibility. Thus feedback values can be stored in an intemnediate memory by input commands 
and can be used further through additional commands (e.g. SMS-PP). As It is shown in figure 5 the mobile service 

40 program code is stored in its own EF (elementary file) 6 in the GSM file system 4. Commands are divided into groups 
such as: GUI, data handling, SMS-PP send/receive and operational control (jump, if-then-else, ...). Referring now to 
figure 3 it will be explained how the mobile service data and the mobile service program codes are transmitted as data 
packets. A data packet consists of a header and a data region. The header contain 10 bytes. The value stored in the 
header Indicate to the interpreter platform 3 how the data container should be handled. Among other information, the 

45 header contains the number of associated and sent packets as well as the corresponding packet numbers. A further 
value defines what should be done with the received packet (e.g. embedded mobile service code execute, display 
data, store packets, etc.). 

[0040] As shown in figure 5, the data packets are stored in the EF^jat^ 7 in the GSM file system 4. The stored data 
contains the current data and the header such as erased, used to updateable. The interpreter platform applet 3 requires 

50 this information for its "memory management". Thus it can be shown which data may be overwritten or not 

[0041] A packet contains so-called data containers in the data region. How much. and how large the individual con- 
tainers are is not specified. The number and the size of the data containers Is determined and stored in the header. 
There are data containers which carry for example telephone numbers separated by the dividing symbol Thus the 
mobile phone user can use a display of these points to contact directly the corresponding person via the number. 

55 [0042] As shown particularly in figure 5, the interpreter platform applet 3 is divided Into two functionally separated 
regions, i.e. a receiving part and a interpreter part 13. The actual interpreter part 13 loads the mobile service code out 
of the EF^3p 6 and processes it (interpretation and execution). If a command requires data to be processed, then this 
will be loaded out of the Bf^^^ 7. If there is no data In the memory for the actual mobile service application, these data 
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. win be obtained via the SI\^S-PP from the host (or server). 
[0043] The SMS-PP reception part (receiving part) 3 evaluates incoming SMS-PP. Received data pacl<ets are auto- 
matically stored in the EF^ata 7- clata packets received contain so-called "embedded mobile service program 
codes", then this is immediately executed. This allows the separate and single execution of codes. The application 
5 data is not evaluated by the interpreter 1.3 but only held in the data containers. This can be stored, displayed or trans- 
mitted by SMS-PP. 

[0044] By means of simple data administration and efficient commands, it is possible to produce mobile telephone 
applications which are SMS based with very little mobile service program code. The application "agenda" should show 
this as an example. 

10 [0045] The agenda allows the user to show the schedule of the current day or requesting new schedules as required 
through a menu. In addition the user should also be able to view all the schedules of the current month. When schedules 
are changed, the data is automatically provided to him from the office. Finally, the agenda should be able receive the 
schedule input. The memory requirement for the agenda application according to the present invention needs only 
about 1 50 bytes. 

15 [0046] The mobile service program code for the command to display the menu looks as follows: 



* '. 




li^^m ' '^'^ " ^ ' ' ^ ^ 










' V...- ' v l 








0x01 


0x03 


Schedule day; schedule month ; 
new schedule; 


0x00 OxOA 


0x00 OxOB 


0x00 OxOC 



25 [0047] This command displays a menu with three items on the mobile phone. An address is allocated to each item 
to which the code part for the correspond function is attached. If item 2 is selected, the program operation is executed 
from address 0x00 OxOB. 

[0048] The method "show data" has a central role in the interpreter platform (JAVA applet) 3. The show data command 
is very powerful and can be accessed in various modes. Thus highly flexible program solutions are possible. According 

30 to the application, the detailed view of an individual point is possible or other functions such as the direct dial of a 
telephone number or the selection of an entry. The command "show data" actually consists of some loops, branches 
and the GSM "select item" and "display tags" commands. This method only uses data for display which is stored in 
the corresponding EF under the above-mentioned application number. The mobile service program code is guaranteed 
to remain compact through the comprehensive options integrated in the "show data" command. 

35 [0049] Figure 6 shows different applications for the present invention. 

[0050] In figure 7 it is again shown how agenda data from a PC 1 1 can be transferred to the mobile telephone 8. As 
already explained, the agenda data are transferred to a server 9 converting the data into SMS-PR messages to be 
transmitted to a SMS centre 1 0. The SMS centre 1 0 transmits wirelessly the SMS-PP messages by means of the SMS 
service 1 to the mobile telephone 8. 

40 [0051] The process for the menu item "agenda" is once again shown with reference to figure 8. The mobile service 
is started In step S1 . In step S2 the user selects the menu point agenda. In step S3 the user selects the menu point 
update and a conresponding SMS-PP Is sent to the server 9. In step S5 the interpreter platform waits for the SMS-PP 
from the server 9. In step S6 the conresponding message "agenda updated" is received and the process goes back to 
step S3. In case In step S3 the item "show agenda" Is selected, the agenda is shown in step S7 and the processes ends. 

45 [0052] When particularty compared to the so-called WAP technology, the WAP technology has the disadvantage that 
It requires a voice channel, a WAP-capable mobile telephone as well as an internet site which is especially dedicated 
for WAP application. The present invention is based for example on SMS and therefore does not need a dedicated 
voice channel. As only a very small data quantity needs to be transmitted, the costs for the user are significantly cheaper. 
[0053] The following 1 8 commands are defined (see Annex 1). 

50 

Java Applet 



[0054] The interpreter applet is divided Into two functionally separated regions. The actual interpreter part and the 
SMS receiving part. The interpreter part loads the mobile service program (MSP) code and interprets the commands. 
55 The SMS receiving module process the received SMS-PP data. According to the Data Packet Header the data will be 
stored or further processed. Moreover, the interpreter applet controls the function for the memory management and 
the security part. Special configuration settings of the JAVA applet will be stored in the Config- Memory. The applet 
manages the followed memories: 
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M-Service program memory (51 2- n Bytes, SIM-Card dependent) 
InBuffer (120 Bytes) 

Embedded M-Service program memory (ca. 120 Bytes) 
Jump-table (ca. 40 Bytes) 
5 SMS-PP memory (memory of Incoming data; 'receiving memory*) 

Configuration memory 

Mobile Service Server Software 

10 [0055] Thie mobile service server software is divided into three function sections: 

The management of the mobile service program code which are sent to the mobile phone and the processing of the 
Incoming and outgoing SMS-PP data packets. The third module is responsible for accessing user data out of other 
systems !il<e Lotus Notes, Exchange Server, database management systems, etc. 

[0056] The user can with the client software on his workstation configure the mobile service and adjust to his needs. 
15 The client software is available as own application, as HTML-Intranet/Internet-Site and as WML (WAP), too. Therefore, 
it can also be configured via mobile phone. 
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[0057] 
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Table of Commands: 

Show Menu 

Function: Displays a menu on the Mobile Phone. If a menu point will be selected, the 
program will jump at the according address. 



Opcode: SEM ByteCode: 01 

Syntax: SHM < Numbers of Items > < Iteml > ; < Item2 > ; < Adr. I High > < Adr. I 
Low > < Adr .2 I-High > < Adr .2 Low > 

20 ByteCode:01 < IByte > < n-Bytes > ; <n-Bytes > ; <High-Byte > < Low-Byte > < High- 
Byte > <LowByte> 



E.g.: 0102Mail read;Mail write;00500090 

Play Tone 

Function: Makes a sound. This key corresponds to predefined s.ounds/melodies 
(according to the SIM-Toolkit standard) . 



Opcode: PLT ByteCode: 02 

Syntax : PLT < Key (sound) > < Duration- Art > < Duration > 

ByteCode: 02 < 1 Byte >< 1 Byte >< 1 Byte > 



duration-art: 00 = min, 01 = sec, 02 = 1/10 sec 
''^ duration: unites of 0-255 



E.g.: 02017F 
Numeric Input 



Function: Allows user-input. The handed over text will be displayed as title. For the input 
only the signs '0' to *9\ and are allowed. 
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OpCode: NUI ByteCode: 03 

Syntax: NUI < Mode > < Text Len > < Displayed-Text > 

ByteCode: 03 < 1 Byte > < 1 Byte> <n-Bytes> 

Mode: 00 = replace data in InBuf, 01 = complement data in InBuf 
(dividing symbol *:') 

E.g.: 030107Number: 

Alphanumeric Input 

Function: Allows user-input. The handed over text will be displayed as title. For the 
input all signs of the SMS- Alphabets are allowed. 

OpCode: AU ByteCode: 04 . 

Syntax: AU < Mode > < Text Len > < Display ed-Tcxt> 

ByteCode: 04 <1 Byte > <1 Byte> <n-Bytes> . 

Mode: 00 = replace data in InBuf, 01 = complement data in InBuf 
(dividing symbol *:') 

E.g.: 040105Name:. 

Show Data 

Function: Creates out of one or several Data Container (DC) a menu. Only DC*s will . 

be used, which correspond to the handed over application-ID. According to 
the adjustment of Mode, details of the menu points can be selected and 
displayed. 

OpCode: SHD ByteCode: 05 

Syntax : SHD < Application ID > < Mode > 
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ByteCode: 05 < 1 Byte> < 1 Byte> 

Mode 00 - Displays the data on display-width, no detail display 
Mode 01 - Displays the data on display- width and detail display 
Mode 02 - Display the data on display-width mth selection possibility 
Mode 03 - like Mode 01 with selection possibility 

E.g.: 050A00 

Write Display 

Function: Displays a text on the Mobile Phone display. 
OpCode: WRD ByteCode: 06 

Syntax: WRD<Mode> [<Len Text><Text>] 
ByteCode : 06 < 1 Byte > [ < I Byte > < n-By tes > ] . 



Mode 00 - Displays a text and removes it again after a certain waiting-time 
Mode 80 - Displays a text and waits of user-input 

Mode 01 - Displays InBuf and removes it again after a certain waiting-time 

Mode 81 - Displays InBuf and waits of user-input 

Mode 03 - Displays InBuf + text display and removes it again after a 

certain 

waiting-time 

Mode 83 - Displays InBuf + text display and waits of user-input 



E.g.: 



06080DMail received 



Set OTA Number 



Function: 



Sets the telephone number of the used OTA- Server. All further setid 
SMS-PP commands will use this OTA-number. 



Opcode: 



SON 



ByteCode: 07 



Syntax: 



SON<Len Number > <int. Number > 
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ByteCode: 07 < 1 Byte > < n-Bytes > 
E.g.: 070B+4117758555 
Send SMS-PP 

Function: Sends text and/or InBuf on the selected OTA-server. 
OpCode: SSM ByteCode: 08 

Syntax: SSM < Application ID > < Mode > [ < Len Data > < Data > ] 
ByteCode: 08 < 1 Byie> < 1 Byte>[< 1 Byte> <n-Bytes>] 



Mode 00 - only < Data > transmission 
25 Mode 0 1 -only variable transmission 

Mode 02 - <Data> + //z^z// transmission 



E.g.: 08010204cmd = 
Wait for SMS-PP 

Function: Waits for a response-SMS of the OTA-server. Depending on the Mode, data 
will be written in the application memory (data-memory) or in the internal 
memory (InBuf). 



Opcode: WSM ByteCode: 09 

45 Syntax: WSM < Mode > [ < Len Text > < Text > ] 

ByteCode: 09<lByte> 



Mode 00 - waiting without text display 
Mode 0 1 -waiting with text display 



E.g. : 09010CWait for SMS 
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IF-Then-Else 

Funccion: Compares the handed over expression with the InBuf The comparison 
operators are 'equal' and 'not equal*. 

OpCode: ITE ByteCode: 11 

Syntax: ITE < Len Expression > < Expression > < Then Jumping- Address > < Else . 
Jumping-Address > 

ByteCode: OB<lByte> <n-Bytes> < High-Byte > < Low-Byte > < High-Byte > 

< Low-Byte > 

< expression > : < logic operation > < comparison operator > 
logic operation = data in InStr = with comparison operator 

E.g.: OB05=Test00900000 
Jump 

Function: Absolute jump-address. The program will continue the workflow on the 
handed over address. 

OpCode: JMP ByteCode: 12 

Syntax: JMP < Jump-Address > 

ByteCode: OC < High-Byte > < Low-Byte > 

E.g.: OCOOOO 

Store InBuf 

Function: The internal Buffer (InBuf) will be stored in the application memory under 
the handed over ID number. Moreover, the Type of Data Container (ToDC) 
will always be set on 01 (InBuf). 

OpCode: SIB ByteCode: 14 
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Syntax: SIB < Application ID > 
ByteCode: OE<lByte> 

Remark: It will always been written in the block-number 1 . 
E.g^: OiEOl 
Load InBuf 

Function: Loads a saved InBuf. 
Opcode: LIB ByteCode: 15 

Syntax: LIB < Application ID > 
ByteCode: OF < 1 Byte > 

Remark: Always the block-number 1 will be loaded. 

E.g.: OFOl 

Run Stored Embedded VMC 

Function: Loads a Stored Embedded VMC conmiand-sequence and executes it 
immediately. 

OpCode: REV ByteCode: 16 

Syntax: REV < Application ID > 
ByteCode: lO<lByte> 
Remark: 

E.g.: 1005 
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Set DataCotainer Status 



Function: 



The status of all Data Container in the application memory will be set on the 
new value. 



Opcode; 



SDS 



ByteCode: 17 



10 



IS 



20 



25 
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50 



Syntax: SDS < Application ID > < New Status > 
ByteCode: IK 1 Byte> < 1 Byte> 

Stams: 00 = free, 0 1 = used, 02 = update, 99 = set all free 

Remark: 

E.g.; llOlOO 
Run APDU-Command 

OpCode: RAC ByteCode: 18 

Function: Executes the APDU-Command. The result will be stored in the InBuf. 
Syntax: RAC < Mode > < Len APDU-Command > < APDU-Command > 
ByteCode: 12 < 1 Byte >< 1 Byte > < n-Bytes > 



Mode: 00 = only execute (immediately executed), 01 = execute and store 
in InBuf, 02 = only execute if previous command was correct (InBuf), 
result in InBuf 



Internal Buffer (InBuff) 

So that data of user- input, user-output and data which are send by SMS-PP can be 
spooled (intermediate memory storage), a InBuffer has been defined. The data in the 
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InBuffer can be overwritten or added. The size of the InBuffer is max. 119 bytes, this 
corresponds to the max. number of signs which caii be transmitted by SMS-PP. 



InBuffer 




Information of Data-Size 


Usable Data 


1 Byte 


118 Byte 



Data Packets 

The data are sent in Data Packets by SMS-PP. The values stored in the header indicate 
to the Interpreter-Applet (PARS) how the Data Container should be handled. 

the structure is defined as followed: 



Data Packet (118 Bytes) 


1 Byte 


1 Bvtc 


1 Byte 


1 Byte 


1 Byte 


1 Byte 


1 Byte 


1 Byte 


1 Byte 


1 Bvte 


308 Bytes 


Type 


App.-ID 


Packet 
-Nr. 


ToDC 


Number of 
Packets 


Number 
of DC 


UnDC 
high 


LenDC 
low 


Res. 


Res. 


Usable Data 



01 Command-sequence (M-Service) for storing 

02 User-data for storing 

03 Data for InBuff 

04 Embedded M-Service code for immediate 
execution 

05 OTA-Server command 

00 Reserved 

0 1 -1 27 Application-Number 

01-127 Actual Packet-Number 

00 Stored M-Service code 

01 InBuffer 

02 Data Container with embedded telephone number 

03 User data 

01-127 Total number of the packets which have 
to be transmitted 

01-127 Number of Container in the usable data 



Type: 



App,-ID: 
Packet-Nr.: 

ToDC (Type of Data Container): 

Number of Packets: 

Number of DC (Data container): 



1143688A1_I _> 
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Len DC high: 
Len DC low: 



00-01 Length of data in container (High- Byte) 
00-127 Length of data in container (Low-Byte) 



Data Container 



10 



The Data Containers are hold in the usable data region of the Data Packets. The usable 
data region can include 1 - n Data Container. The number and the size of the Data 
Containers is stored in the header of the Data Packets, 
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Usable Data (108 Bytes) 



Data Container 1 | Data Container 2 



Data Container 3 



Data Container 4 



20 



25 



30 



Data storage 

If the Data Packets get stored, the structure of the Data Packets stays considerable the 
same. Only the first byte of the header (type) will be replaced through the status byte, 
which includes information about the memory status of the Packets. 



Data Packet (118 Bytes) 


1 Byte 


I Byte 


1 Byte 


1 Byte 


1 Byte 


1 Byte 


1 Byte 


1 Byte 


1 Byte 


1 Byte 


108 Bytes 


Type 


App.-ID 


Packet 
-Nr. 


ToDC 


Number of 
Packets 


Number 
of DC 


Len DC 
high 


Len DC 
low 


Res. 


Res. 


Usable Data 



35 



40 



Legend: 



Status: 00 free 

01 in use 

02 update possible 
The rest like Data Packet 



45 



50 



55 



Claims 



2. 



Method for performing mobile services on a mobile device (8) having a 
microprocessor smart card (2), 
characterized In that 

downloaded mobile service program codes (4) are respectively executed by means of an 
interpreter platform (3) for performing a mobile service. 

Method according to claim 1, . 
characterlzed'in that 

mobile service data needed for performing the mobile services are transmitted (1 ) to the 
mobile device (8) and stored on the microprocessor smart card (2), wherein the 
interpreter platform (3) accesses the mobile service data for performing the 
corresponding mobile service. 
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3; Method according to claim 2, 
characterized in that 
. the mobile service data are stored In the microprocessor smart card (2). 

4. Method according to anyone of the preceding claims, 
characterized in that 

the interpreter platform (3) is divided in an interpreter part (13) for processing mobile 
service program codes and a receiving part (12) for transmitting data to-and/or from a 
remote server (9). 

5. Method according to anyone of the preceding claims, 
characterized in that 

the transmission of mobile service program codes and/or mobile sen/ice data is 
perfomied over a non-voice channel (1 ). 

6. Method according to anyone of the preceding claims, 
characterized in that 

the mobile service program codes are downloaded by means of the SMS sen/Ice (1) of a 
GSM transmission system. 

7. Method according to claim 6, 
. characterized In that 

the mobile sen/ice program code necessary for a mobile sen/ice Is assembled In a server 
(9) and then transmitted to the mobile device (8) by means of a SMS service (1). 

8. Method according to anyone of the preceding claims, 
characterized In that 

single modules of the mobile service program code can be downloaded. 

30 9. Method according to anyone of the preceding claims, 
characterized in that 

the Interpreter platform (3) consists of methods, wherein each method is associated with 
a dedicated memory file (6) for storing the mobile service platfomi code to be executed 
by said method. 

35 

10. Method according to anyone of the preceding claims, 
characterized in that 

the transmission of mobile service program codes and/or mobile sers^ice data is 
perfomied by means of data pac)<ets having a header and a data region. 

40 

11. Software program for executing a method according to anyone of the preceding claims when Implemented on a 
microprocessor smart card (2) of a mobile device (8). 

12. Microprocessor smart card for a mobile device having stored thereon an interpreter 
45 platform for executing a method according to anyone of claims 1 to 11 . 

13. Mobile telephone having a microprocessor smart card according to claim 12. 

50 Amended claims in accordance with Rule 86(2) EPC. 

1. Method for performing mobile services on a mobile device (8) having a microprocessor smart card (2), 
characterized by the steps of: 

55 . downloading a mobile service program code (4), 

downloading mobile service data, 

storing the downloaded mobile service program code (4) and the mobile service data on the microprocessor 
smart card (2), 
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executing the downloaded mobile service program code (4) by means of an Interpreter platfonn (3) for per- 
forming a mobile service, 

wherein the downloading of mobile service program codes and mobile service data is performed over a non-voice 
channel (1) of an air interface. 

2. Method according to claim 1 , 
characterized in that 

the mobile service program code is downloaded in single modules. 

3. Method according to claim 1 or 2, 
characterized in that 

moblie service data needed for perfomning the mobile services are transmitted (1) to the mobile device (8) and 
stored on the microprocessor smart card (2), wherein the interpreter platform (3) accesses the mobile service data 
. for perfonning the corresponding mobile service. 

4. Method according to anyone of the preceding claims, 
characterized In that 

the interpreter platfonn (3) is divided in an interpreter part (13) for processing mobile service program codes and 
a receiving part (12) for transmitting data to and/or from a remote server (9). 

5. Method according to anyone of the preceding claims, 
' characterized in that 

the mobile service program codes are downloaded by means of the SMS service (1) of a GSM transmission system. 

6. Method according to claim 5, 
characterized in that 

the mobile service program code necessary for a mobile service is assembled in a server (9) and then transmitted 
to the mobile device (8) by means of a SMS service (1 ). 

7. Method according to anyone of the preceding claims, 
characterized in that 

the Interpreter platform (3) consists of methods, wherein each method is associated with a dedicated memory file 
(6) for storing the mobile service platform code to be executed by said method. 

8. Method according to anyone of the preceding claims, 
characterized in that 

the transmission of mobile service program codes and/or mobile service data is performed by means of data 
paclcets having a header and a data region. 

9. Software program for executing a method according to anyone of the preceding claims when implemented on 
a microprocessor smart card (2) of a mobile device (8). 

10. Microprocessor smart card for a mobile device having stored thereon an interpreter platform for executing a 
method according to anyone of claims 1 to 8. 

11 . Mobile telephone having a microprocessor smart card according to claim 10. 
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